Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Option 1 solution for #2112 #2115

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from
Open

Option 1 solution for #2112 #2115

wants to merge 1 commit into from

Conversation

xee5ch
Copy link
Contributor

@xee5ch xee5ch commented Feb 22, 2025

Committer Notes

This approach adjusts the oscal-catalog-control-require-statement-when- not-withdrawn constraint to look at the core NIST and non-core namespace for parts to properly constrain the required existence of a statement or withdrawn prop status value for NIST-specific catalog use cases.

If merged, closes #2112.

All Submissions:

By submitting a pull request, you are agreeing to provide this contribution under the CC0 1.0 Universal public domain dedication.

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Changes to Core Features:

  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you written new tests for your core changes, as applicable?
  • Have you included examples of how to use your new feature(s)?
  • Have you updated the OSCAL website and readme documentation affected by the changes you made? Changes to the OSCAL website can be made in the OSCAL-Pages and OSCAL_Reference repositories.

@xee5ch
Option 1 check namespaces for usnistgov#2112
877d172 
This approach adjusts the oscal-catalog-control-require-statement-when-
not-withdrawn constraint to look at the core NIST and non-core namespace
for parts to properly constrain the required existence of a statement or
withdrawn prop status value for NIST-specific catalog use cases.
@xee5ch xee5ch requested a review from a team as a code owner February 22, 2025 02:56
@xee5ch xee5ch mentioned this pull request Feb 22, 2025
Open
@iMichaela
Copy link
Contributor

@xee5ch - Thank you for submitting the two options. This option is expecting in the test that the core OSCAL's namespace is included explicitly, and I believe that the community follows the guidance that anywhere where the ns is not included, it is assumed core OSCAL's namespace is to be considered.
@RS-Credentive started a related conversation on OSCAL Lobby, long ago. I wonder what would be the impact for the community and I would like to hear from the community members. We might need to explain the approach and implications to them for both options.

@xee5ch
Copy link
Contributor Author

xee5ch commented Feb 22, 2025

This option is expecting in the test that the core OSCAL's namespace is included

I can double check with software but that is not quite the specification and processing model docs describe. The core @ns is implicit and you can still explicitly check its value. At least that is how it should have always worked or other cases would have to much more complex logic. This rationale is why either the code before or after the change #2114 worked for which I'd also like a review. Notice document instance values are checked in many places even if the developer or their software don't explicitly include it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@xee5ch @iMichaela